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(54) Method and system for integrating security mechanisms into session initiation protocol 
request messages for client-proxy authentication 



(57) A method and system is provided to integrate 
the Kerberos security mechanism into the message flow 
of the signaling operation under the Session Initiation 
Protocol to allow a SI P client and a SIP proxy to authen- 
ticate each other. When the SIP proxy receives an re- 
quest message, such an INVITE request, from the SIP 



client, it responds with a challenge message indicating 
that authentication based on Kerberos is required. In re- 
sponse, the SIP client sends a second request message 
with a proxy authorization header containing authenti- 
cation data, including a Kerberos server ticket for the 
Proxy, to allow the proxy to authenticate the client's user. 
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Description 
RELATED CASES 

5 [0001] This application claims the priority of U.S. Provisional Application No.60/298.239, filed June 14. 2001 . 
TECHNI CAL FIELD OF THE INVENTION 

[0002] This invention relates generally to communications between devices over a computer network, and more 
10 particularly to the integration of a security mechanism, such as one based on the Kerberos authentication protocol, 
into network communications that use the Session Initiation Protocol (SIP) as the signaling protocol for establishing a 
communication session. 



15 



BACKGROUND OF THE INVENTION 



[0003] The Session Initiation Protocol (SIP) is a signaling protocol that provides a mechanism for a computing device 
to locate another device it wants to communicate with over a computer network arid to establish a communication 
session therewith. SIP is a versatile protocol and has been used for establishing communication sessions in many 
different scenarios. For instance, SIP is used for Interne! conferencing, telephony, presence, event notification, and 
20 instant messaging. An important strength of SIP is its support of personal mobility by providing the ability to reach a 
called party (user) under a single, location-independent address even when the called party has moved to a different 
computer. 

[0004] One common mode of session initiation operation under the SIP is the "proxy mode. 0 By way of example, a 
SIP client (the "caller") may send a SIP request message, such as an INVITE message, identifying the intended recipient 

25 (the "callee") by an e-mail like address. This request message is typically first sent to an outbound SIP proxy of the 
sending SIP client. The outbound SIP proxy then forwards the request message, often through other intermediate SIP 
proxies, to an SIP proxy with which the intended recipient client has registered, which then sends the INVITE to the 
recipient. The acceptance message ( M 200 OK") of the recipient client is returned through the signaling chain to the 
caller, which can then communicate with the callee through a media channel that, is typically different from the signaling 

30 channel. Besides communicating with another SIP client, a SIP client may also talk to SIP servers for purposes such 
as registering itself with a SIP registrar by sending a REGISTER request. 

[0005] Although SIP has been widely implemented for various applications, it was designed mainly for signaling 
operations. It does not explicitly provide or require a security mechanism for protecting the security and privacy of the 
communication sessions. In many cases, however, it is desirable to require a SIP client that sends a request to au- 

35 thenticate its user to an outbound SIP proxy, and to also require the proxy to authenticate itself to the SIP client. 
Moreover, it is also often necessary to protect the integrity of the SIP request messages. Both the client-proxy authen- 
tication and message integrity require the use of a reliable security mechanism. Thus, there is a need to combine a 
reliable security mechanism with the SIP signaling operation to allow authentication between a SIP client and an out- 
bound SIP proxy. The technical challenge is, however, how to fit the desired security mechanism into the SIP signaling 

40 framework so that the two mechanisms for different purposes can be performed together effectively. 

SUMMARY OF THE INVENTION 

[0006] In view of the foregoing, the present invention provides a scheme to integrate a security mechanism, such 
45 as.the Kerberos protocol or the NTLM protocol, into the message flow of the SIP signaling operation to allow a SIP 
client and a SIP proxy to authenticate each other. In accordance with the invention, when the proxy receives a SIP 
request message from the SIP client, it responds with a challenge message indicating that authentication according 
to a pre-selected security mechanism is required. In response, the SIP client sends a second, or revised, version of 
the request message with a proxy authorization header that includes authentication data for authenticating the client 
so to the server according to the security mechanism. In the case where the Kerberos security mechanism is used, the 
proxy authorization header includes data representing a Kerberos server ticket obtained by the client for accessing 
the proxy. If the authentication of the client's user based on the proxy authorization header data is successful, the SIP 
proxy forwards the request through the SIP message signaling path between the SIP client and the intended recipient 
of the request message. H the SIP client requires mutual authentication, the SIP proxy adds a proxy authentication 
55 information header to the next message it sends to the client. This message may be, for example, a "200 OK" SIP 
response generated by a callee SIP client in response to an INVITE request or a "200 OK" response generated by a 
SIP registrar server in response to a REGISTER message. The proxy authentication information header contains the 
authentication data for the client to authenticate the SIP proxy. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

[0007] While the appended claims set forth the features of the present invention with particularity, the invention, 
together with its objects and advantages, may be best understood from the following detailed description taken in 
conjunction with the accompanying drawings of which: 

Figure 1 is a block diagram generally illustrating an exemplary computer system on which the present invention 
may be implemented; 

FIG 2 is a schematic diagram showing a Session Initiation Protocol (SIP) system including a SIP client and a SIP 
proxy server that authenticate each other during a session signaling phase; 

FIG. 3 is a schematic diagram showing exchange of signaling messages between the SIP client and the SIP proxy 
server for authentication purposes; 

FIG. 4 is a schematic diagram showing a state machine representing the operation of security mechanisms in 
conjunction within the framework of SIP; 

FIG. 5 is a schematic diagram showing exchange of signaling messages for the SIP client to perf orm authentication 
operations with multiple SIP proxies; 

FIG. 6 is a schematic diagram showing the message flow in a process of pre-authentication between the SIP client 
and the proxy using the Kerberos security mechanism; 

FIG. 7 is a schematic diagram showing the message flow in a challenged-aulhenlication process between the SIP 
client and the proxy using the Kerberos security mechanism; 

FIG. 8 is a schematic diagram showing the message flow in a challenged-authentication process between the SIP 
client and the proxy using the NTLM security mechanism; and 

FIG. 9 is a schematic diagram showing the message flow in a process of pre-authentication between the SiP client 
and the proxy using the NTLM security mechanism. 

DETAILED DESCRIPTION OF THE INVENTION 

[0008] Turning to the drawings, wherein like reference numerals refer to like elements, the invention is illustrated as 
being implemented in a suitable computing environment. Although not required, the invention will be described in the 
general context of computer-executable instructions, such as program modules, being executed by a personal com- 
puter. Generally; program modules include routines, programs, objects, components, data structures, etc. that perform 
particular tasks or implement particular abstract data types. Moreover, those skilled in the art will appreciate that the 
invention may be practiced with other computer system configurations, including hand-held devices, multi-processor 
systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe 
computers, and the like. The invention may be practiced in distributed computing environments where tasks are per- 
formed by remote processing devices that are linked through a communications network. In a distributed computing 
environment, program modules may be located in both local and remote memory storage devices. 
[0009] The following description begins with a description of a general-purpose computing device that may be used 
in an exemplary system for implementing the invention, and the invention will be described in greater detail with ref- 
erence to FIGS. 2-9. Turning now to FIG. 1 , a general purpose computing device is shown in the form of a conventional 
personal computer 20. including a processing unit 21 , a system memory 22, and a system bus 23 that couples various 
system components including the system memory to the processing unit 21 . The system bus 23 may be any of several 
types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a 
variety of bus architectures. The system memory includes read only memory (ROM) 24 and random access memory 
(RAM) 25. A basic input/output system (BIOS) 26, containing the basic routines that help to transfer information between 
elements within the personal computer 20, such as during start-up, is stored in ROM 24. The personal computer 20 
further includes a hard disk drive 27 for reading from and writing to a hard disk 60, a magnetic disk drive 28 for reading 
from or writing to a removable magnetic disk 29, and an optical disk drive 30 for reading from or writing to a removable 
optical disk 31 such as a CD ROM or other optical media. 

[0010] The hard disk drive 27, magnetic disk drive 28, and optical disk drive 30 are connected to the system bus 23 
by a hard disk drive interface 32. a magnetic disk drive interface 33, and an optical disk drive interface 34. respectively. 
The drives and their associated computer- readable media provide nonvolatile storage of computer readable instruc 
tions, data structures, program modules and other data for the personal computer 20. Although the exemplary envi- 
ronment described herein employs a hard disk 60, a removable magnetic disk 29, and a removable optical disk 31 , it 
will be appreciated by those skilled in the art that other types of computer readable media which can store data that is 
accessible by a computer, such as magnetic cassettes, flash memory cards, digital video disks. Bernoulli cartridges, 
random access memories, read only memories, storage area networks, and the (ike may also be used in the exemplary 
operating environment. 
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[0011] A number of program modules may be stored on the hard disk 60, magnetic disk 29, optical disk 31 . ROM 
24 or RAM 25. including an operating system 35, one or more applications programs 36, other program modules 37, 
and program data 38. A user may enter commands and information into the personal computer 20 through input devices 
such as a keyboard 40 and a pointing device 42. Other input devices (not shown) may include a microphone, joystick, 
game pad, satellite dish, scanner, or the like. These and other input devices are often connected to the processing unit 
21 through a serial port interface 46 that is coupled to the system bus, but may be connected by other interfaces, such 
as a parallel port, game port or a universal serial bus (USB) or a network interface card. A monitor 47 or other type of 
display device is also connected to the system bus 23 via an interface, such as a video adapter 48. In addition to the 
monitor personal computers typically include other peripheral output devices, not shown, such as speakers and print- 



10 ers. 



ers. 

[0012] The personal computer 20 may operate in a networked environment using logical connections to one or more 
remote computers, such as a remote computer 49. The remote computer 49 may be another personal computer, a 
server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the 
elements described above relative to the personal computer 20, although only a memory storage device 50 has been 
15 illustrated in Fig. 1 . The logical connections depicted in Fig. 1 include a local area network (LAN) 51 and a wide area 
network (WAN) 52. Such networking environments are commonplace in offices, enterprise-wide computer networks, 
intranets and the Internet. 

[0013] When used in a LAN networking environment, the personal computer 20 is connected to the local network 
51 through a network interface or adapter 53. When used in a WAN networking environment, the personal computer 

20 20 typically includes a modem 54 or other means for establishing communications over the WAN 52. The modem 54, 
which may be internal or external, is connected to the system bus 23 via the serial port interface 46. In a networked 
environment, program modules depicted relative to the personal computer 20, or portions thereof, may be stored in 
the remote memory storage device. It will be appreciated that the network connections shown are exemplary and other 
means of establishing a communications link between the computers may be used. 

25 [0014] In the description that follows, the invention will be described with reference to acts and symbolic represen- 
tations of operations that are performed by one or more computers, unless indicated otherwise. As such, it will be 
understood that such acts and operations, which are at times referred to as being computer-executed, include the 
manipulation by the processing unit of the computer of electrical signals representing data in a structured form. This 
manipulation transforms the data or maintains it at locations in the memory system of the computer, which reconfigures 

30 or otherwise alters the operation of the computer in a manner well understood by those skilled in the art. The data 
structures where data is maintained are physical locations of the memory that have particular properties defined by 
the format of the data. However, while the invention is being described in the foregoing context, it is not meant to be 
limiting as those of skill in the art will appreciate that various of the acts and operations described hereinafter may also 
be implemented in hardware. 

35 [001 5] Referring now to FIG. 2, the present invention is directed to a way to integrate a security mechanism, especially 
one implementing the Kerberos authentication protocol, into the request messages under the Session Initiation Protocol 
(SIP) to enable a SIP client 72 and a SIP proxy server 74 to authenticate each other and for protecting the integrity of 
the signaling messages. The SIP is defined in Request For Comments (RFC) 2543, which is hereby incorporated by 
reference in its entirety. 

40 [0016] By way-of example, as shown in FIG. 2, in a typical session initiation operation, a user 76 (e.g., "Ann") of a 
SIP client 72 (the "caller") that wants to talk to another user 80 (e.g., "Bob") sends an INVITE message 82 that identifies 
Bob as the intended recipient for the INVITE. This INVITE is sent to an outbound proxy server 74 for the caller SIP 
client's domain. As shown in FIG. 2, the INVITE message may be passed through multiple SIP proxies involved in the 
signaling operation before it reaches the SIP client 86 (the callee) of Bob's computer 88. In a preferred embodiment, 

45 the security of the SIP signaling messages being transferred between the SIP proxies in the signaling path is protected 
by sending the messages under the I PSec protocol or through a pipe under the Secured Sockets Layer (SSL) protocol. 
It will be appreciated that although in this example the SIP request is an INVITE request, the authentication scheme 
described below can also be used for other types of SIP requests, such as REGISTER, MESSAGE, SUBSCRIBE, 
SERVICE, etc. 

so [0017] For ensuring the security of the signaling operation and the integrity of the signaling messages, the outbound 
SIP proxy server 74 may require authentication of the user 76 of the caller SIP client 72 before forwarding the INVITE 
message 82 through the signaling path 90. In accordance with the invention, referring now to FIG. 3, the proxy server 
74 responds by sending a challenge message 96 to the SIP client 72. The challenge message 96 contains the status 
code "407 Proxy Authentication Required" as defined in the SIP specification for indicating that the client 72 has to 

55 first authenticate the user with the proxy 74. Pursuant to the SIP specification, the challenge message 96 {referred to 
hereinafter as the "407 message") includes a "Proxy-Authenticate" header field 98 that contains data indicating the 
security mechanism the client should use for authentication. The syntax and contents of the Proxy -Authenticate header 
is described in greater detail below. In a preferred embodiment, Kerberos is the preferred security mechanism, but the 
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SIP framework also allows the use of the security mechanism based on the NTLM protocol, in the following description, 
it is assumed that a security mechanism based on the Kerberos protocol is used unless otherwise indicated. 
[0018] Still referring to FIG. 3 f when the SIP client 72 receives the 407 message 96 from the proxy server 74 in 
response to the INVITE message 82, it decides from the Proxy-Authenticate header 98 that the proxy server requires 

s authentication of the user by means of the Kerberos mechanism. The client 72 then obtains a server ticket 108 from 
a Kerberos Key Distribution Center (KDC) 100 for the SIP proxy server 74 if it has not already obtained one. In one 
implementation., tbe KDC 100 is part of the domain controller 102 for the proxy server 74. After obtaining the server 
ticket 108, the client 72 sends another INVITE message 110. This time, however, the INVITE message 110 includes 
a Proxy-Authorization header field 112, pursuant to the SIP specification. The Proxy-Authorization header field 112 

io includes the server ticket 1 08 for accessing the proxy, which includes the session key 1 1 6 to be used. The syntax and 
contents of the Proxy-Authorization header field is described in greater detail below. Optionally, the Proxy-Authorization 
header may also include a request for mutual-authentication, i.e.. asking the proxy server 74 to authenticate itself to 
the client 72. 

[0019] When the SIP proxy server 74 receives the resent INVITE message 110 with the Kerberos server ticket em- 
's bedded therein, it extracts the server ticket and verifies the validity of the ticket by decrypting it with its long-term key 
shared with the KDC 100. If the ticket is valid, the user 76 is authenticated, and the SIP proxy server 74 forwards the 
INVITE message 110 to the next proxy 120 on the signaling path. If the client 72 has requested mutual authentication 
in the Proxy-Authorization header 112 of the INVITE message 110, the proxy server 74 will sign future packets from 
the server to the client using a session key associated with the Kerberos server ticket. This message includes a Proxy- 
20 Authentication Information header 1 24 that contains the credentials of the proxy 74 to allow the client 72 to authenticate 
the proxy. 

[0020] Ultimately, the INVITE message 110 reaches the catlee, i.e., the SIP client 86 of Bob's computer 88. If the 
callee accepts the call invitation, it returns a "200 OK" message 126, which is then routed back to the caller. Once the 
call connection is established, the caller can communicate with the callee directly without having to go through the SIP 

23 proxies involved in the signaling phase. 

[0021] Referring now to FIG. 4 f in accordance with the invention, the operation of establishing the authentication 
security association (SA) with between the SIP client 72 and the SIP proxy server 74 can be viewed as a state machine 
128. In the embodiment shown in FIG. 4, the preferred security mechanism is Kerberos, but optionally the NTLM 
security mechanism can also be used, and the state machine diagram reflects the inclusion of that option. 

30 [0022] In FIG. 4, the states are shown in circles, and the operations performed in connection with the states are 
shown in rectangular blocks. As shown in FIG. 4, one state in the state machine is the "SECURITY_STATE_NONE" 
state 132, in which no security SA has been established. When the client 72 receives a 407 challenge from the proxy 
74 in response to an INVITE sent by the client or when the client decides to do a p re-authentication with the proxy, the 
client enters into a "SECURITY_STATE_ACQUIRING_SA" state 136, in which the client acquires the security associ- 

35 ation data required for authentication, which depends on the security mechanism selected. 

[0023] Generally, the security association is defined as a state in which the client and the SIP proxy have exchanged 
a shared secret in a secure manner such that this secret can be used to authenticate and protect the integrity of any 
subsequent messages exchanged by the client and the proxy. If the security mechanism is Kerberos, the security 
association includes the Kerberos server ticket for the proxy and the session key. In the case of Kerberos, the obtained 

40 SA is complete, i.e., it is sufficient for the proxy to authenticate the user of the SIP client. The client then sends this 
SA-related information (e.g., Kerberos session key encrypted with the server's secret) to the proxy (step 138). If the 
proxy sends back a signed 200 OK message (step 140), the authentication is successful and the security association 
is established, i.e., the dient is in the SA Established state 142. If, however, the proxy sends a 407 challenge instead 
(step 146), the client assumes that the proxy is in a bad state so that it cannot validate the client's good credentials. 

-*s The client then waits for a "back-off time (e.g., 5 minutes) before trying to send SIP messages again (step 148). 

[0024] After entering the SA Established state 1 42 , the client can send further messages to the proxy without having 
to do the authentication again, as long as the security association has not expired. If. however, the proxy sends a 407 
challenge (step 150), the client assumes that the proxy has for some reason dropped the established security associ- 
ation. As a result, the client enters the SA Dropped state 156, and moves back to the 

50 SECURITY_STATE_ACQUIRING_SA state 136 to acquire a new SA for redoing the authentication with the proxy. 
[0025] As mentioned above, the NTLM mechanism can be optionally selected for user authentication. The state 
migration for NTLM is largely identical to that for Kerberos, but with the difference that the NTLM acquires only a partial 
SA the first time (step 1 58), and sends the incomplete SA to the proxy in a first message. More specifically, in the case 
of NTLM.. the first request from the client with the SA related information carries the client's security related capabilities 

55 (e.g., the version of the protocol it supports, the signing algorithms it supports, etc.) In response, the server sends a 
second 407 challenge (step 160) that contains its a own authentication data : including its NTLM related capabilities 
and a random byte string typicafly called "nonce". In response, the client signs a hash of its own name and the "nonce" 
value sent by the proxy using its credentials. This is handled internally by the NTLM implementation. The server verifies 
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the client's authentication data and gets the session key with the help of the domain controller. If the SIP proxy is not 
the intended recipient, it then forwards the SIP request to the next hop in the signaling path , and signs the next message 
(e.g., a 200 OK message from the recipient) to the sender SIP client (step 140). 

[0026] The syntax of the various SIP headers involved in the message exchange between the SIP client and the SIP 
s proxy for authentication purposes is described below. 

Th e 407 R esponse 

[0027] As mentioned above, if the SIP proxy server 74 wants to challenge the identity of the SIP client (or its user) 
io that sent an INVITE message, it sends a 407 message with a Proxy-Authenticate header back to the client. The syntax 
of Proxy-Authenticate header in a preferred embodiment requiring the use of the Kerberos security mechanism for 
authentication is as follows: 

r5 Proxy-Authenticate= "Proxy-Authenticate" scheme kerb- challenge 
gssapi-data 



Scheme = "kerberos" I W NTLM" i "Negotiate" 

kerb- challenge « 1#{ realm | targetname | [ opaque ] | qop- 

options | ggssapi-data ) 
targetname * "targetname" " = " <"> URI ( 1*SP URI ) 

<"> 

URI » absoluteURI | abs_path 

opaque = "opaque" ,r -" quoted-string 

os qop-opticns = "qop M <"> l#qop- value <" > 

qop- value = "auth" | "auth-int" | token 

gssapi-data * "gssapi-data" M =" ( token | quoted-string) 



25 



30 



40 

[0028] The syntax of the Proxy- Authenticate header described here is similar to the H WWW-Authenticate Response 
Header defined in IETF RFC 2617 entitled "HTTP Authentication: Basic and Digest Access Authentication " which is 
hereby incorporated by reference in its entirety. The optional parameters "algorithm" and "stale" have been dropped. 

45 The "scheme" field of the header allowsthe client to choose which authentication mechanism among the ones proposed 
by the server it wants to use to authenticate itself to the server. The client preferably chooses the Kerberos mechanism 
if it can support that mechanism ; and otherwise chooses the NTLM authentication mechanism. 
[0029] The realm parameter is the unique identifier of the SIP service provider to which the SIP proxy belongs and 
the client is trying to access. The realm string is displayed to the user to help her identify the correct set of credentials 

so she needs to provide in order to authenticate. The "targetname" parameter is a always required and is used to carry 
the FQDN for the SIP proxy. The actual contents of this parameter help the client to keep track of which proxy it is 
establishing an SA with. It helps the proxy to determine whether the response is meant for itself or some other proxy. 
The "opaque" parameter is used by the server to index the particular SA being established and has to be echoed in 
any future Proxy-Authorization header the client generates for the SA, as will be described below. 

55 [0030] in this embodiment; it is assumed that the Generic Security Service Application Programming Interface 
(GSS-API) as defined in IETF RFC 2078 (which is hereby incorporated by reference in its entirety) has been imple- 
mented and is used for securely exchanging messages between communicating applications. The GSS-API allows, 
among other things, a communicating application to authenticate the user associated with another application. The 
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gssapi-data field in the Proxy-Authenticate header and the Proxy-Authorization header described below is for holding 
the data returned during the SA negotiation phase by the Security APIs that implement NTLM and Kerberos security 
packages. These APIs return the gssapi data that need to be sent from the client to the proxy and vice versa. The 
. gssapi data are opaque to the SIP client and proxy implementation and are interpreted only by the security API. The 
s qop parameter tells the client the level of security the server wants to client to adhere to. The qop parameter value is 
always set to "auth" indicating the security level provided by this mechanism is user authentication. 
[0031] The following is an example of a Proxy-Authenticate header field: 

10 Proxy-Authenticate: Negotiate 

realm="Microsof t RTC Service provider" , 
opaque = "ABCDEF4 567 89" 

15 

qop = "auth", 

gssapi-data = "ABCD345678yuikjhlbcdf saqwety" 

20 

[0032] Typically the SIP proxy would challenge the identity of the SIP client if it is provisioned to allow only authorized 
clients and the incoming SIP packet from the client does not contain any signature. The SiP proxy would also challenge 
a client if it has lost the security association for this SIP UR! (due a reboot, etc.). If there is a mismatch between the 
authorization parameters that the client is using and what the SIP proxy is expecting, the SIP proxy would challenge 
25 the client using a 407 message carrying the exact authorization parameters that SIP proxy wants the client to comply 
with. 

Client's Response to a 407 Challenge 

30 [0033] In response to a 407 challenge, the SIP client would try to generate a signature complying with the authen- 
tication parameters sent by the SIP proxy through the 407 challenge message. The SIP client would increment the 
Cseq value and resend the initial SIP request that was challenged along with the authorization information carried in 
a Proxy-Authorization request header. The syntax of the Proxy-Authorization request header in a preferred embodiment 
is as follows: 

35 [0034] Proxy-Authorization = "Proxy-Authorization" ":" scheme kerb-response realm message-qop targetname 



40 



45 



50 



55 
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10 



kerb-response = 1# ( [crand] | [response] | [opaque] 

[gssapi-data] ) 

»qop M qop-value 
"crand" M =" crand -value 
crand-value 

"response" request -digest 

<«> 32LHEX <"> 



message-qop 
crand 

crand-value 
response 
request-digest 



15 


LHEX 


= ■ o " | 


"1" j 


»2" 


"3" 






n ^ it 


| "5 tt 


| "6" 


| "7" 


20 




ft g ii 


| "9" 


| "a" 


| "b M 






n q it 


1 "d" 


I "e" 


1 "f 



25 

[0035] The syntax of the Proxy-Authorization header described here is similar to the "Authorization Request Header" 
defined In IETF RFC 261 7, except that the optional parameters "algorithm" and "URl" have been dropped. The Proxy- 
Authorization header is added after the request URl and the Via headers The signature is computed using the session 
key across following fields. 

The From header URl 
The To header URl 
The From header tag 
The To header tag 

The "crand" parameter in the Proxy-Authorization orthe "srand" parameter in the Proxy-Authentication-Info header 
The Expires value in the SIP message Expires header. The message body of the SIP message is not included in 
the signature. A proxy-authorization header contains either the gssapi-data parameter or the response (signature) 
parameter. 

40 [0036] The following are examples of a Proxy-Authorization header in a client's response to a 407 challenge: 



30 



35 



45 



50 



55 



Proxy-Authorization : Negotiate 

realm* "Microsoft RTC Service Provider" , 

response="ABCD87564cvx", 

opaque- "ABCD1234", 

crand - "1234" 

qop - "auth" 

targetname » "serverl . domainA. microsoft . com'' 



OR 
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Proxy- Authorization : Negotiate 

realm="Microsof t RTC Service Provider", 

5 

opaque- "ABCD1234", 



>* gssapi-data - "ABCDEF123456", 

qop = w auth", 

targetname = "serverl.domainA.microsoft.com" 

15 

[0037] Besides responding to a 407 challenge from the proxy, the client would also send this header when it registers 
with the SIP proxy for the first time. The Proxy-Authorization header would contain the "gssapi-data" parameter when 
Ihe SIP clienl registers with the proxy server and is in the process of initialising a security association for a session. 

20 

Mutual Authentication 

[0038] Establishing a mutual authentication between the SIP proxy and the SIP client might be required in certain 
deployment scenarios. The client finds out from the provisioning profile it has for the particular proxy server whether 
^5 mutual authentication is required or not. If the mutual authentication is enabled, the client initializes its security asso- 
ciation for mutual authentication, using the standard version of the GSS API. Also, if mutual authentication is enabled, 
the server needs to sign every packet it sends to the SIP client. This signature is carried in the Proxy-Authentication- 
Information request header. The syntax of the Proxy-Authenticate-lnformation is as follows: 

30 

ProxyAuthenticationlnfo = "Proxy-Authentication-Inf o" " : 11 

auth-info 

35 



auth-info = 1#( message-qop| response-auth | srand ) 

response -auth = "rspauth" " = " response -digest 
response-digest * <"> *LHEX <"> 
srand - "srand" srand -value . 

srand-value ■ quoted-string 



so [0039] The "rspauth" parameter in the Proxy-Authentication- Info header carries the signature (of the authenticating 
proxy) for this response. The "srand" parameter is used by the server after the SA establishment phase to sign the 
messages it sends to the client. This parameter is a random string generated by the server itself and is used to introduce 
an element of randomness in the hash/signature of the message generated, 
[0040] The following is an example of the Proxy-Authentication- Information: 

.55 
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Proxy- Authentication- Info: Negotiate 

realm= "Microsoft RTC Service Provider", 

5 

qop = "auth", 

rspauth * u ABCD87564cvx", 
" srand = "9876543210", 

targe tname= " serverl . domainA . microsoft . com" 

15 

[0041] Generally, in the SIP framework, a SIP client may establish a security association with a SiP proxy during a 
registration process using a REGISTER request. The registration allows the SIP client to receive messages from the 
SIP proxy. When the SIP client registers with the SIP proxy, it can at the same time authenticate its user with the SIP 
proxy server by sending Ihe authentication data, such as a Kerberos ticket, along in the REGISTER message. If ihe 
20 SIP client has already registered and authenticated itself with the SIP proxy, when the client sends a SIP request, such 
as an INVITE, the request message from the client will be signed using the Kerberos session key exchanged during 
the SA establishing process. 

[0042] Nevertheless, a SIP client is not required to register with the server before it can send out a request message 
to the SIP proxy. In the case where the caller has not authenticated itself with the proxy (even if the SIP client has 
25 already registered with the proxy), the SIP proxy does not forward the request to the next hop. Instead, the proxy sends 
a challenge to the SIP client. 

[0043] The challenge indicates that the client needs to establish a security association with this SIP server. The client 
can establish the SA by resending the request with the security association data, , or alternatively it can do so by 
refreshing its registration with this server if one is already in place but the SA has not been established. Establishing 
30 the SA using the registration refresh and then sending the SIP request with a valid signature has the advantage that 
it also makes sure that the registration is in a good state. 

[0044] Also, every time a SIP client un-registers with SIP proxy, the security association (SA) between the two is lost 
and a new security association has to be negotiated again. Moreover when the registration of a SIP client expires, the 
proxy server will remove its corresponding security context from its list of SAs. Every time a SIP client refreshes its 

35 registration it has to refresh the authentication security association. 

[0045] in a preferred embodiment that uses a security mechanism based on the Kerberos protocol, a Kerberos ticket 
is requested from a Kerberos Key Distribution Center (KDC) every time the SIP client registers with the SIP proxy if 
the authentication of the user of the sending SIP client is required by the SIP proxy/registrar. When the SIP client 
receives the Kerberos ticket, it decrypts this ticket. The decrypted ticket contains the session key and some other 

40 properties of this Kerberos session This ticket also contains the session key and other session related parameters 
encrypted with the server's credentials. This part is returned in a pOutput parameter in the gssapi-data field and is sent 
in the re-INVITE request to the proxy. 

[0046] To facilitate a clear understanding of the operation of the security mechanism within the framework of SIP, a 
particular example of client-to-proxy Kerberos authentication is described below with reference to FIG. 2. In this ex- 

45 ample, it Is assumed that the SIP proxy server 74 has created a shared secret key with the KDC 170 in the domain 
"domainA. Microsoft.com: S_serverV\ where "serverl" is used in this example as the code name for a SIP proxy/ 
registrar. The KDC 170 knows the proxy server 74 as server JD ^serverl .domainB.microsofl.com. The proxy server 
74 also acquires a credentials handle to be ready to respond to an incoming authentication request from the client. 
Server credentials are used to authenticate the proxy server 74 to the SIP client 74 in security protocols that support 

so server authentication or mutual authentication.' The proxy server 74 obtains a handle to its credentials defined by the 
service account used to start the server. It does so by calling the function AcquireCredentialsHandie of the Security 
Support Provider Interface (SSPI). 

[0047] In the example of FIG. 2 ; the user 76 of the SIP client 72 is Ann. Ann has an account in an NT domain and 
logs' on her account when she starts the day with the following information: 

55 
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User ID / principal name=* ann@microsof t .com 
P-ref erred_email = ann@microsoft.com 
User_domain « domainA.Microsoft.com 
Workstation = annl.domainA.Microsoft.com 

w 

[0048] When Ann wants to call Bob : she starts the SIP client 72 on her workstation 78 {the SIP client may start 
automatically as a service but should run in the security context of the user). The SIP client 72 finds its outbound proxy 
server 74 using DNS. The outbound proxy server 74 to use in this example is identified as Serverl .domainB. Microsoft, 
com. Ann indicates that she wants to talk to bob@microsoft.com. Her SIP client 72 then sends an INVITE message 
15 82 to Serverl .domainB.Microsott.com. The INVITE message includes the following information: 

INVITE bob@microsoft.com 
From: ann@microsoft.com 
To: bob@microsofl.com 

20 

[0049] For purposes of keeping the description of the example concise and clear, not all data contained in this INVITE 
message or other messages exchanged in the signaling processing are shown. The SIP proxy server 74 has been 
configured to require that all INVITE requests be authenticated for calls made to the Microsoft.com user name space. 
As a result, the SIP proxy server 74 responds to the INVITE by sending a 407 message 96 asking the SIP client 74 to 
25 use Kerberos to authenticate the user Ann. The 407 message includes the following data: 



Proxy-Authenticate : Kerberos realm=domainB . Microsoft . com 
30 targetnaiiie - "serverl.domainA.Microsoft.com" opaque = 

" sorneopaquedata" 

35 

[0050] The opaque value is initialized by the proxy to identify the security context to use for this call. To that end, the 
proxy server 74 calls the function AcceptSecurityContext at this time and returns in opaque the base64 encoded result 
of pOutput. The opaque value is used by the client and server to identify a security context to use for a particular server 
for the purposes of authentication continuation or reauthentication of subsequent requests to the same server using 

40 the Authorization request header. 

[0051] When the SIP client 72 on Ann's workstation gets the 407 message 96 indicating that authentication is re- 
quired, it checks if it has a valid session key for talking to Serverl .domainB.Microsoft.com. If it does not have one yet, 
it needs to contact the KDC in its domain to get a session key for accessing the outbound SIP proxy. In this example, 
the client knows from the realm specified in the 407 message that the proxy is in a different domain than its own. 

45 [0052] To establish a secured connection to the proxy server 74, the client 72 acquires an outbound credentials 
handle before sending an authentication request to the proxy. This is performed by calling functions of SSPI. The SSPI 
provides the means for networked applications to call one of several security support providers (SSP) to establish 
authenticated connections and to exchange data securely over those connections. There are two client-side SSPI 
functions involved in the authentication setup. The AcquireCredentialsHandle function obtains a reference to previously 

so obtained logon credentials. The function InitializeSecurityContext creates the initial authentication request security 
tokens. The call to initializeSecurrtyContext passes in the p/npuMhe opaque value obtained from the 407 message. 
The client sets a tfContextReq parameter of the function to request MUTUAL_AUTH. A pfContextAttr pointer is the 
way the Kerberos module 180 tells the client that mutual-auth has been "requested". This information is part of the 
KERB_AS._REQ created by the Kerberos module 180 of the client and passed in a secBuffer (pOutput) that tells the 

55 server (here the SIP proxy) the client wants mutual authentication. Since this is part of the KERB request, there is no 
need for a SIP mechanism (header/parameter) to request mutual authentication. 

[0053] In the example shown in FIG. 2, calling the API function InitializeSecurityContext. causes the following Ker- 
beros logic to happen. First, the client 72 asks the KDC 1 70 for the domainA.Microsoft.com domain to give it a server 
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ticket to the Proxy server 74 in DomainB. The KDC 1 70 for domainA.Microsoft.com sends the client 72 a referral ticket 
to the KDC 1 72 for corp Microsoft.com. This referral ticket is encrypted in the inter-domain key shared by the two KDCs. 
With the referral ticket, the client asks the KDC 172 for corp.Microsoft.com to give it a server ticket to the server in 

[0054] In response the KDC 1 72 sends the client a referral ticket to the KDC 1 76 for DomainB This ticket is encrypted 
in the inter-domain key the KDC 1 72 shares with the DomainB KDC 1 76. The client then asks the KDC 1 76 for DomainB 
to give it a ticket to the proxy server 74 in DomainB. The KDC 176 sends back a server ticket 108 for accessing the 
proxy server 74. The KDC 1 76 encrypts one copy of this session key with Ann's logon session key, and embeds another 
''^^J/tVuMt O ^ c ion i^v in th ft ean/ertlricftt, Alonq with Ann's authorization data, and encrypts the server ticket with the 
;S U ;^^ — ls "acK to the client 72 in a Kerberos Ticket- 

S ^Tcati SlSSSSSi- thus causes the Kerberos module 180 of the C.ien, machine to initiate a 
TGS exchange with the KDC. The value returned by this exchange is the session key for signing messages to be sent 

rooSr^ereafter, the SIP c.ient 72 creates a new INVITE message 110 (also called the "re-INVITE" message).to 
be sent lo the SIP proxy. This new INVITE message 110 includes a proxy-authonzaiion header as descnbed above, 
with the GSS-API data therein containing the server ticket the client received from the KDC 176. The sess.on key ,s 
me value returned in the pOurpufbuffer returned by the initializeSecurityContext call. Thus,the new INV.TE message 
110 includes the following data: 



INVITE bob@microsoft.com 
From: ann@microsoft.com 
To: bob@microsoft.com 

Proxy-authorization: gss-scheme opaque gssapi-rdata 
25 Opaque = someopaquedata 

Gssapi-rdata = base64 {pOutput} = session key to the proxy 

This INVITE does the equivalent of a KRB_AP_REQ to the proxy server. 

[0057] To protect the integrity of the messages and authenticate itself (i.e., prove the source , oj message), the 
Sent Signs the INVITE message 110 with the session key. Otherwise a third party could sniff the INVITE get the 
Opa uTand Gssapi-data values and send a bogus INV.TE to the same server to make a call M£nj^«d 
whatever destination it chooses. This means a client's authentication could be "stolen; for as long as the session key J*- 
(8 hrs by default). Signing the INVITE doesn't stop a third party from grabbing the Opaque and Q 
GsIapMata. but it can stop that party from creating a new INVITE to call whomever it wants. The server would have 
to be configured to only accept signed requests for this problem to be avoided. 

0058? The client 72 uses the MakeSignature API and calls it for setting the phContext to the secunty context used ^ 
In this call (the one identify in the opaque of the 407) and passing the content to sign in pMessage. The output of this 
call is returned in pMessage. The client adds the signature to the INVITE 110. When the proxy 

server 74 receives the resent INVfTE message 11 0. it checks the opaque value in the Proxy-Authorization header and 
collates it with a given phContext value (handle to a given security context). It takes the gssapi-rdata out and passes 
it to its Kerberos module 182 by cal.ingthe AcceptSecurityContext API function and passing the gssapi-rdata value 
obtained from the proxy-authorization header Iq the plnput component of the API function. The Kerbems . modute 182 
decrypts the server ticket using the .ong-term key of the proxy, and extracts Ann's authorization data and the session 
kev ft uses the session key to decrypt Ann's authenticator and then evaluates the timestamp inside. 
005 ) < t e auSnSr passes the test, the Kerberos module 182 looks for a mufual authentication flag In the 
client's request If the flag is set. the Kerberos module 1 82 uses the session key to encrypt tne time from Ann s au- £p 
Sa o and returns the result in a Kerberos Application Reply (KRB_AP„REP). This causes the call to AcceptSe- 
curityContex, to return a SEC_E. OK return value with the authenticator passed through the API using itiie £ Oup« 
buffer Oncetheuseris authenticated, the SIP proxy/registrar will process the request and forward the INVITE message 
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rproxvJauthentica^or so that the client can authenticate the server. In the illustrated example, the message , a 
"200 Of? message. This message is not originated by the SIP proxy. Rather, the 200 response is generated : by he 
callee in response to the INVITE request. The SIP proxy merely signs it with the session key before forwarding this 

SET/S SISdS above the authenticator is in the Proxy-Authentication-lntorma.ion header. The header a.so 
includes the opaque value for the client to match this response to the right security context. 
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[0062] When the SIP client 72 on Ann's workstation receives the "200 OK" message, it extracts the Proxy-Authen- 
tication-Information header and calls InitializeSecurityContext with the phContext value set top the value in opaque 
and the plnput buffer set to response-digest. The Kerberos module 1 80 on the client decrypts the proxy's authenticator 
with the session key it shares with proxy and compares the time returned by the proxy with the time in the client's 
5 original authenticator. If the times match, the call to InitializeSecurityContext will return a SEC_E_OK and the client 
knows that the proxy is genuine. Else, the client should drop the call. There is no point in sending a CANCEL to kill 
the call since the client cannot trust the server to do anything it asks it to do. 

[0063] In the example described above, the authentication occurs in a scenario in which the SIP first sends an INVITE 
without authentication, and then sends the authentication data in another INVITE in response to a 407 message from 

10 the proxy indicating that authentication is required. Alternatively, the client can include the required authentication data 
in the first INVITE sent to the proxy. To that end, the client 72 obtains the server ticket for the proxy from the KDC 1 76 
before it is used by the user to make a call under SIP. The authentication data required are then put in the Proxy- 
Authorization request header as described above. Doing this avoids the need for the proxy to send the 407 challenge 
to the client to ask for authentication data. Also, even though only one SIP proxy is involved in the example of authen- 

15 tication operation described above : there are typically multiple SIP proxies in the SIP signaling path between the caller 
and thecallee, and more than one of them may require the caller's client for authentication. For instance, in the simplified 
case shown in FIG. 5, there is another SIP proxy server 120 in additional to the outbound proxy server 74 of the SIP 
client, and both proxies require client authentication before forwarding the INVITE message. In this case, the client 72 
first goes through the same process as described above in connection with FIG. 4 to authenticate itself wilh the outbound 

20 SIP server 74. After the proxy server 74 authenticates the client, it sends the INVITE to the second proxy 1 20, which 
then sends a 407 challenge 190 to the client. 

[0064] In response, the client sends another new INVITE 192 with a Proxy- Authorization header containing a Ker- 
beros server ticket for the second Proxy server 1 20. After authenticating the client, the second proxy passes the INVITE 
192 to the callee. 

25 [0065] The following description provides additional examples of how the Proxy Authenticate, Proxy Authorization, 
and Proxy-Authentication Information headers are used in scenarios of different message flows for performing authen- 
tication based on the Kerberos or NTLM security mechanism. Turning to FIG. 6 f in this case, the SIP client 72 performs 
a Kerberos-based pre-authentication when the client registers with the proxy server. The client sends a REGISTER 
request 200 that includes a Proxy-Authorization header containing the Kerberos server ticketfor the proxy and a request 

30 for mutual authentication as described above. After authenticating the client based on the server ticket, the proxy 
returns a 200 OK message 202 with a Proxy Authentication Information header containing the proxy's authentication 
data that the client can use to authenticate the proxy. Exemplary contents of the REGISTER and 200 OK messages 
are as follows. 

[0066] REGISTER sip:nickn@microsoft.com SIP/2.0 

35 
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Via: SIP/2 . O/UDP www .xxx v yyy . zzz : 5060 
From: "Nick North" <sip :nickn@microsof t . com> 
5 To: "Mark Mars" <sip :markmmarkm@microsof t .com> 

Call-ID: l23456789@microsof t .com 
CSeq: 1 REGISTER 

10 

Contact: <sip : 123 . 45 . 67 . 89 : 5060> 

Proxy- Authorization: Negotiate 
« realm= "Microsoft RTC Service Provider", qop - "auth", gssapi- 
data = "34fcbaed78902QWERTY", targetname^ 
" server 1 . doaminA . microsoft . com" 

20 

User-Agent: Microsof t-RTC/1 .0 
Content -Length: 0 

25 

SIP/2.0 200 OK 

30 

Via: SIP/2. 0/UDP www. xxx. yyy .222 : 506 0 

Proxy- Authentication- Info: Negotiate qop* auth, rspauth= 
35 M ABCD87564cvx", srand = "S876543210" realm* "Microsof t RTC 

Service Provider" targetname= w serverl .doaminA. microsof t . com" 

40 

From: "Nick North" <sip :nickn@microsof t . com? 
To: "Mark Mars" <sip:markm®microsof t .com> 
45 Call-ID: 123456789@ms.com 

CSeq: 1 REGISTER 

Contact: "Nick North" <sip: 8www. xxx. yyy . zzz> 

50 

User-Agent: Microsof t-RTC/1 . 0 
Content -Length: 0 

55 

{0067] FIG. 7 shows a scenario of Kerberos-based challenged authentication. In this example, the client 72 first 
sends an INVITE 206 without any Proxy-Authorization information to the proxy 74. The proxy responds with a 407 
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message 208 wilh an Proxy-Authenticate header to indicate that authentication is requires. In respond to the 407 
message, the client sends a REGISTER request 210 with a Proxy-Authorization header containing the required Ker- 
beros authentication data. The Proxy returns a "200 OK" message 212 with a Proxy Authentication Information header 
containing authentication information about the proxy itself. After authenticating the proxy based on the data in the 
Proxy Authentication Information header, the client sends a second INVITE 214 with the Proxy-Authorization header. 
Exemplary messages in this process are provided below. 

SIP/2.0 407 Proxy Authorization Required 
Via: SIP/2. 0/UDP www . xxx . yyy. zzz : 5060 
From: "Nick North" <sip:nickn@microscf t .com> 
To: "Mark Mars" <sip:markm@microsoft .com> 
Call-ID: 1234 5600@PC1 .ms.com 
CSeq: 1 INVITE 

Proxy- Authenticate : Negotiate realms "Microsoft RTC Service 
Provider", targetname =" serverl.dbaminA.microsoft.com", qop = 
"auth" 

Contact: <sip:123 .45 . 67 . 89 : 5060> 
User-Agent: Microsoft -RTC/1 . 0 
Content -Length: 0 

REGISTER sip: nickn@microsoft.com SIP/2.0 
Via: SIP/2. 0/UDP www. xxx .yyy . zzz : 5060 
From: "Nick North" <sip :nickn@microsof t . com> 
• To: '"Mark Mars" <sip:markm@microsof t .com> 
Call-ID: 123456789@microsoft.com 
CSeq-: 1 REGISTER 

Contact: <sip:123 .45 . 67.89 : 5060 > 

Proxy -Authorization: Negotiate realm= "Microsoft RTC 
Service Provider", opaque^ "ABCD1234", qop = "auth", gssapi- 
data = "34fcbaed78902QWERTY" 
targetname= " serverl . domainA . microsoft . com " 
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User -Agent: Microsof t-RTC/l . 0 
Content -Length: 0 



SIP/2.0 200 OK 
1Q Via: SIP/2. 0/UDP www.xxx.yyy. zzz:5060 

Proxy-Authentication- Info: Negotiate qop= "auth", 
rspauth= V ABCD87 564cvx" , srand » "9876543210" 

15 , 

targetname="serverl . doaminA. microsof t . com" reaims "Microsoft 
RTC Service Provider", 
20 From: "Nick North" <sip : nicknOmicrosof t . com> . 

To: "Mark Mars" <sip:markm@microsof t ,com> 

Call-ID: 123456789@ms.com 

25 

CSeq: 1 REGISTER 

Contact: <sip:123.45.67.89:5060> 
30 User -Agent: Microsof t-RTC/l . 0 

Content -Length: 0 



35 [0068] Turning now to FIG. 8, as mentioned above, in a preferred embodiment the NTLM security mechanism can 
be optionally used for the ciient-proxy authentication. In this case, the client first sends an INVITE message 220 without 
authentication data, and the proxy returns a 407 message. The Proxy Authenticate header of this 407 message 222 
indicates that NTLM should be used for authentication. The client then sends a REGISTER message 224 with a Proxy 
Authentication header containing the authentication data of the client according to the NTLM protocol. 

40 [0069] As mentioned above in connection with the state machine of FIG. 4, the authentication data sent by the client 
allows the proxy to authenticate the client but the security association is not completely established based on the 
authentication data, so the proxy sends another 407 challenge 226 to the client, again with a Proxy Authenticate header. 
The client then sends another REGISTER request 228, with a Proxy Authorization header containing the authentication 
data required to complete the security association. The proxy server completes the security association based on the 

45 data in the second REGISTER request and returns a "200 OK" message 232 with a Proxy Authentication Information 
header containing authentication data about the proxy. Based on the authentication data in the "200 OK h message 
232, the client authenticates the proxy, and then sends out another INVITE message 236. Exemplary messages for 
this process are provided below. 

50 
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SIP/2.0 407 Proxy Authorization Required 
Via: SIP/2. 0/UDP www.xxx.yyy . zzz : 5060 
From: "Nick North" <sip: nickn©microsof t .com> 
To: "Mark Mars" <sip:markm@microsof t . com> 
Call-ID: 1234SS00OPC1. ms.com 
CSeq: 1 INVITE 

Proxy-Authenticate: NTLM realm= "Microsoft RTC Service 
Provider" , targe tname* ■ server 1 . domainA. microsoft. com" , 
opaque="ABCD1234" , qop » "auth" 



..120?5A6A2J..> 
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Contact: <sip:123.45.67.89:5060> 
User-Agent: Microsoft -RTC/l . 0 
Content -Length: 0 

REGISTER sip:nickn@microsof t .com SIP/2,0 
Via: SIP/2.0/UDP www.xxx.yyy ,zzz: 5060 
From: "Nick North" <sip: nickn@microsof t . com> 
To: "Mark Mars" <sip: rnarkm@microsof t . com> 
Call-ID: i-23456789@microsof t .com 
CSeq: 1 REGISTER 

Contact: <sip:123.45.67.89:5060> 

Proxy-Authorization: NTLM realms "Microsoft RTC Service 
Provider", opaque^ "ABCD1234", qop - "auth"., gssapi-data 
" 34 f cbaed7 8902QWERTY" 

targe tname= n serverl . domainA . microsoft . com" 

User-Agent: Microsoft -RTC/l . 0 
Content -Length: 0 

SIP/2.0 407 Proxy Authorization Required 
Via: SIP/2 . 0/UDP www.xxx.yyy.zzz : 5060 
From: "Nick North" <sip:nickn@microsof t .com> 
To: "Mark Mars" <sip :markm@microsof t . com> 
Call-ID: 12345600©PCl.ms.com 
CSeq : 1 INVITE 
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Proxy-Authenticate: NTLM realms "Microsoft RTC Service 
Provider" , targe tname-" serverl.domainA.microsoft.com", 

5 f 
opaque» ,, ABCD1234 M , qop « "auth", 

gssapi-data = "QWERTY789564NMJHKLasdcf g" 

ro Contact: <sip : 123 . 45 . 67 . 89 : 5060> 

User-Agent: Microsof t-RTC/l . 0 

Content -Length: 0 

75 

REGISTER sip:nickn@microsof t .com SIP/2.0 
20 via: SIP/2. O/UDP www . xxx . yyy . zzz : 5060 

Prom: "Nick North" <sip:nickn@microsof t .com> 
To: "Mark Mars" <sip :markm@microsof t . com> 

25 

Call-ID: 123456789@microsoft .com 
CSeq: 2 REGISTER 
30 Contact: <sip:123-.45.67.89:5060> 

Proxy-Authorization: NTLM realm= "Microsof t RTC Service 
Provider" , gssapi -data = "qqertyuioKMNFO09876" opaque= 

35 

"ABCD1234", qop = "auth", 
targetname= "serverl . domainA. microsof t . com" 
40 User- Agent : Microsoft -RTC/ 1 . 0 

Content -Length: 0 

45 

SIP/2.0 200 OK 

Via: SIP/2. O/UDP www.xxx.yyy. zzz : 5060 
Proxy-Authentication- Info: NTLM realm* "Microsof t RTC 

Service Provider" qop« "auth", 
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rspauth= "ABCD87S64cvx", srand = "9876543210" 
targetname= M serverl . domainA. microsoft .com" 

From: "Nick North" <sip:nickn@microsof t . com> 
10 To: "Mark Mars" <sip : markmOmicrosof t . com> 

Call- ID : 1234 5678 9@ms.com 
CSeq: 2 REGISTER 

15 

Contact: <sip:123.45.67.89:5060> 
User-Agent: Microsoft-RTC/l.O 
20 Content -Length:. 0 

INVITE sip: markm@proxyl.wcom.com SIP/2-0 

55 

Via: SIP/2. O/UDP www. xxx.yyy. zzz : 5060 

Proxy- Authorization: NTLM realm^'Microsof t RTC Service 
30 Provider" , crand= ,, 913082051»' , 

response="12345ABCDEF78909BCADE56", opaque= "ABCD1234", qbp V 
M auth" , targetname= n serverl .domainA . microsoft . com" . 
35 From: "Nick North" <sip :nickn@microsof t . com> 

To: "Mark Mars" <sip : markm@microsof t . com> 
Call- ID: 12345601@PC1 .ms .com 

40 

CSeq: 2 INVITE 

Contact: "Nick North" <sip:nickn@microsof t .com> 
45 User-Agent: Microsoft-RTC/l.O 

Content -Type : application/sdp 
Content -Length: xxx 

50 1 

[0070] FIG. 9 shows a scenario of NTLM-based pre-authentication. The message flow of this case is similar to that 
of the Kerberos-based pre-authentication, but with the addition of a 407 challenge and a REGISTER message. Spe- 
55 cifically, the client sends a REGISTER message 240 containing a Proxy Authorization header that indicates that NTLM 
is used and contains NTLM authentication data and a request, for mutual authentication. The proxy authenticates ihe 
client based on the received NTLM authentication data and returns a 407 challenge 242 with a Proxy Authenticate 
header. The client then sends a second REGISTER request 244 with a Proxy Authorization header containing the 
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NTLM authentication data for completing the security association with the proxy. The proxy then returns a "200 OK" 
message 246 with Proxy Authentication Information. After authenticating the proxy, the client sends a second INVITE 
message 248 to the proxy. Exemplary messages for this process are provided below. 

REGISTER sip: nickn@microsoft.com SIP/2.0 
Via: SIP/2. O/UDP www . xxx . yyy . 222 : 5060 
From: "Nick North" <sip: nicknOmicrosof t .com> 
To: "Mark Mars" <sip:markm@microsof t .com> 
Cal 1 - ID : 123 4 5 6 78 9@microsof t .com 
CSeq: 1 REGISTER 

Contact: <sip:123.45.67.89:5060> ■ - 

Proxy- Authorization; NTLM realm= "Microsoft RTC Service 
Provider", opaque= "ABCD1234", qop = "auth", gssapi-data * 
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"34fcbaed78 902QWERTY", 

targetname= " serverl . domainA. microsoft .com" 
User-Agent: Microsof t-RTC/1 . 0 
Content -Length: 0 

SIP/2.0 407 Proxy Authorization Required 
Via: SIP/2. 0/UDP www.xxx.yyy.222 :5060 
From: "Nick North" <sip : nickn@microsof t . com> 
To: "Mark Mars" <sip :markm@microsof t . com> 
Call-ID: 12345600@PCl.ms.com 
CSeq: 1 INVITE 

Proxy-Authenticate: NTLM realm=" Microsof t RTC Service 
Provider", targetname serverl.domainA.microsoft.com", 
opaque="ABCD1234", qop = "auth", 

gssapi-data= "QWERTY7 8 9 5 64NMJHKLasdcf g" , 
targe tname= " server! . domainA . microsoft . com" 

Contact: <sip:123 . 45 . 67 . 89 : 5060> 
User-Agent: Microsof t-RTC/1 . 0 
Content -Length: 0 

REGISTER sip: nickn@microsoft.com SIP/2.0 
Via: SIP/2. 0/UDP www. xxx .yyy. zz2 : 5060 
From: "Nick North" <sip:nickn@micr6soft .cbm> 
To: "Mark Mars" <sip:markm@microsof t . com> 
Call-ID: 123456789@microsoft.com 
CSeq: 2 REGISTER 
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Contact: <sip:I23.45.67.89:5060> 

Proxy-Authorization: NTLM realm»"Microsof t RTC Service 
Provider" ,gssapi-data « "qqertyuioKMNFOO.9876" opaque= 
"ABCD1234", qop = "auth", 

targetname=? w serverl .domainA. microsoft . com" 
User- Agent: Microsof t-RTC/1 . 0 
Content -Length: 0 

* SIP/2.0 200 OK 

Via: SIP/2. 0/UDP www .xxx . yyy . zzz : 5060 
Proxy- Authenticat ion- Info: NTLM qop= w auth" f 
rspauth=."ABCD87564cvx", srand- "9876543210", 
targetnanie=" server l . domainA. microsof t .com" 

From: "Nick North" <sip:nickn@microsof t com> 
To: "Mark Mars" <sip:markm@microsof t . com> 
Call- ID: 123456789@ms.com 
CSeq: 2 REGISTER 

Contact: <sip:123.45.67.89:5060> 
User- Agent: Microsof t-RTC/l . 0 
Content -Length: 0 

INVITE, &ip: markm@proxyl . wcom. com SIP/2 . 0 
Via: SIP/2. 0/UDP www.xxx.yyy.2zz : 5060 

Proxy-Authorization: NTLM realm* "Microsof t RTC Service 
Provider", crand-"913082051" , 

response="12345ABCDEF78909BCADE56", opaque^ "ABCD1234", QOP 
x \auth" targetname="serverl .domainA. microsof t .com" 
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From: "Nick North" <sip :nickn@microsof t . cdm> 
To: "Mark Mars" <sip:markm@microsof t ,com> 
Call-ID: 1234S601@PCl.ms.com 
CSeq: 2 INVITE 

Contact: "Nick North' 7 <sip:nickn@microsof t .com> 
User- Agent : Microsoft -RTC/1 . 0 
r5 Content -Type : application/sdp 

. Content - Length : xxx 

20 [0071] In view of the many possible embodiments to which the principles of this invention may be applied, it should 
be recognized that the embodiment described herein with respect to the drawing figures is meant to be illustrative only 
and should not be taken as limiting the scope of invention. For example, those of skill in the art will recognize that the 
elements o? the illustrated embodiment shown in software may be implemented in hardware and vice versa or that the 
illustrated embodiment can be modified in arrangement and detail without departing from the spirit of the invention. 

25 Therefore, the invention as described herein contemplates all such embodiments as may come within the scope of the 
following claims and equivalents thereof. 
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Claims 



1. A computer-readable medium having computer-executable instructions to perform steps by a Session Initiation 
Protocol (SIP) proxy to authenticate a user of a SiP client, the steps comprising: 

receiving a first request message from the SIP client; 
35 determining that the first request message does not contain authentication data for authenticating the user of 

the SIP client; 

sending a challenge message containing a code indicating that authentication is required; 
receiving a second request message from the SIP client, the second request message including a proxy- 
authorization header containing authentication data for authenticating the user of the SIP client according to 
40 a selected authentication protocol; 

authenticating the user of the SIP client using the authentication data in the proxy-authorization header of the 
second request message. 

2. A computer-readable medium as in claim 1 . wherein the first and second request messages are SIP INVITE re- 
45 quests. 

3. A computer-readable medium as in claim 1 , having further computer-executable instructions for performing the 
step of: after successfully authenticating the user of the SIP client, forwarding the second request message to a 
SIP signaling path leading to an intended callee identified in the request message. 

so 

4. A computer readable medium as in claim 1 , wherein the selected authentication protocol is the Kerberos protocol, 
and wherein the authentication data in the proxy-authorization header includes data representing a Kerberos server 
ticket for accessing the SIP proxy. 

55 5. A computer-readable medium as in claim 4. wherein the step of authenticating includes calling a Kerberos module 
to check validity of the Kerberos server ticket and extracting from the Kerberos server ticket a session key for use 
in communicating with the SIP client. 
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6. A computer- readable medium as in claim 1 , wherein the authentication data in the proxy-authorization header 
includes data requesting mutual authentication between the SIP client and the SIP proxy ; and wherein the com- 
puter-readable medium has further computer-executable instructions for performing the step of returning to the 
SIP client a message having a proxy-authentication information header containing authentication data of the SIP 

5 proxy for use by the SIP client to authenticate the SIP proxy. 

7. A computer-readable medium as in claim 1 , wherein the selected authentication protocol is the NTLM protocol. 

8. A computer-readable medium having computer-executable instructions for a Session Initiation Protocol (SIP) client 
to perform steps for authenticating a user of the SIP client to a SIP proxy in connection with initiating a session 
through the SIP proxy, the steps comprising: 

sending a first request message for an intended callee to the SIP proxy; 

receiving a challenge message sent by the SIP proxy in response to the first request message indicating that 
authentication is required; 

constructing a proxy-authorization header containing authentication data for authenticating the user according 
to a selected authentication protocol; 

sending a second request message for the intended callee : the second request message including the con- 
structed proxy-authorisation header. 

A computer-readable medium as in claim 8. wherein the first and second request messages are SIP INVITE re- 
quests. 

10. A computer-readable medium as in claim 8, wherein the selected authentication protocol is the Kerberos protocol, 
and wherein the authentication data in the proxy-authorization header include data representing a Kerberos server 
ticket for accessing the SIP proxy. 

A computer-readable medium as in claim 8 f wherein the step of constructing the proxy-authorization header in- 
cludes obtaining the Kerberos server ticket from a Kerberos Key Distribution Center. 

A computer-readable medium as in claim 11, wherein the proxy-authorization header includes data representing 
a request for mutual authentication between the SIP client and the SIP proxy, and wherein the computer-readable 
medium includes further computer-executable instructions for performing the steps of: 

3$ receiving a response message from the SIP proxy in response to the second request message; 

extracting from a proxy-authentication information header contained in the response message authentication 
data for the SIP proxy: and 

authenticating the SIP proxy based on the authentication data for the SIP proxy extracted from the proxy- 
authentication information header. 

40 

13. A computer-readable medium as in claim 8, having further computer-executable instructions for the SIP client to 
perform the steps of: 

obtaining user authentication data for authenticating the user of the SIP client according to the selected au- 
*5 thenttcation protocol: and 

transmitting a REGISTER message to the SIP proxy for registration with the SIP proxy, the REGISTER mes- 
sage having a proxy-authorization header containing the authentication data for authenticating the user. 

14. A computer-readable medium as in claim 13. wherein the selected authentication protocol is the Kerberos protocol, 
50 and wherein the authentication data for the user include data representing a Kerberos server ticket obtained from 

a Kerberos Key Distribution Center for accessing the SIP proxy. 

15. A computer-readable medium as in claim 8, wherein the selected authentication protocol is the NTLM protocol. 

55 16. A method for a Session Initiation Protocol (SIP) proxy to authenticate a user of a SIP client during a session initiation 
operation, comprising the steps of: 

receiving a first request message from the SIP client: 
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determining that the first request message does not contain authentication data for authenticating the user of 
the SIP client; 

sending a message containing a "407 Proxy Authentication Required" status code to the SIP client to indicate 
that authentication is required: 

5 receiving a second request message from the SIP client, the second request message including a proxy- 

authorization header containing user authentication data for authenticating the user of the SIP client, the user 
authentication data including data representing a Kerberos server ticket for accessing the SIP proxy; 
authenticating the user of the SIP client using the Kerberos server ticket and extracting a session key from 
the Kerberos server ticket for encrypting communications with the SIP client; and 

10 forwarding the second request message to a SIP signaling path leading to an intended callee identified in the 

INVITE message. 

17, A method as in claim 16, wherein the first and second request messages are SIP INVITE requests. 

is 18. A method as in claim 16, wherein the authentication data in the proxy-authorization header in the second request 
messa g e include data requesting mutual authentication between the SIP client and the SIP proxy, and wherein 
the method further includes the step of returning to the SIP client a message having a proxy-authentication infor- 
mation header containing authentication data for use by the SIP client to authenticate the SIP proxy. 

20 19. A method for a Session Initiation Protocol (SIP) client to authenticate a user of the SIP client to a SiP proxy in 
connection with initiating a session through the SIP proxy, the steps comprising: 

sending a first request message for an intended callee to the SIP proxy; 

receiving a challenge message sent by the SIP proxy in response to the first request message indicating that 
25 authentication is required; 

constructing a proxy-authorization header containing user authentication data for authenticating the user, the 
user authentication data including data representing a Kerberos server ticket for accessing the SIP proxy; 
sending a second request message for the intended callee, the second request message including the con- 
structed proxy-authorization header. 

30 

20. A method as in claim 19, wherein the step of constructing the proxy-authorization header includes obtaining the 
Kerberos server ticket from a Kerberos Key Distribution Center. 

21. A method as in claim 19, wherein the step of constructing the proxy-authorization header includes inserting a 
35 request in the proxy-authorization header for mutual authentication between the SIP client and the SIP proxy and 

wherein the method further includes the steps of: 

receiving a response message from the SIP proxy in response to the second request message; 
extracting from a proxy-authentication information header contained in the response message authentication 
40 data for the SIP proxy; and 

authenticating the SIP proxy based on the authentication data for the SIP proxy extracted from the proxy- 
authentication information header. 

A method as in claim 21 , wherein the first and second request messages are SIP INVITE requests. 

A method for a Session Initiation Protocol (SIP) client to perform authentication with a SIP proxy, comprising the 
steps of: 

obtaining authentication data for authenticating the SIP client according to the Kerberos authentication proto- 
50 coL the authentication data including a server ticket for accessing the SIP proxy; 

transmitting a REGISTER message to the SIP proxy for registration with the SIP proxy, the REGISTER mes- 
sage having a proxy-authorization header containing the authentication data. 

24. A method as in claim 23, wherein the proxy-authorization header includes a request for mutual authentication with 
55 the SIP server, and wherein the method further includes the steps of 

receiving a response message from the SIP proxy in response to the REGISTER message; 
extracting from a proxy-authentication information headercontained in the response message authentication 
data for the SIP proxy; and 
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authenticating the SIP proxy based on the authentication data for the SIP proxy extracted from the proxy- 
authentication information header. 

25. A computer-readable medium having stored thereon a data structure representing a Session Initiation Protocol 
(SIP) request message, comprising: 

a plurality of SIP headers including a proxy-authorization header having a data field containing data repre- 
senting a Kerberos server ticket for accessing a SIP proxy; and 
a message body. 

26. A computer-readable medium as in claim 25, wherein the proxy-authorization header has a second data field 
having a signature generated by signing a portion of the SIP request message using a session key associated 
with the Kerberos server ticket. 

27. A computer-readable medium as in claim 25, wherein the SIP request message is a SIP INVITE request. 

28. A computer-readable medium as in claim 25, wherein the SIP request message is a SIP REGISTER request. 



27 



EP 1 267 548 A2 



20 



SYSTEM MEMORY 



(ROM) 



(RAM) 



BIOS 



OPERATING 
SYSTEM 



APPLICATION 
PROGRAM 



OTHER 
PROGRAM 
MOOULES 



PROGRAM 
DATA 



22 
24 

26 
• 25 

35 



PERSONAL COMPUTER 



32 



I 









r 


PROCESSING 




VIDEO 




UNIT 




ADAPTER 










53 



37 



utr 



NETWORK 
INTERFACE 



HARO DISK 

DRIVE 
INTERFACE 


MAG DISK 

DRIVE 
INTERFACE 


OPTICAL DISK 
ORIVE 
INTERFACE 


SERIAL PORT 
INTERFACE 



hand disk 
drive 



Magnetic disk Optical drive 
dnve 



27 



23 



60 



37 



Figure 1 



38 



-6 , 4 

; Mouse 



OPERATING 
SYSTEM 


APPLICATION 
PROGRAMS 


OTHER 
PROGRAM 
MOOULES 


PROGRAM 
DATA 






I 





□ 



47 



Modem 

I 

54 



Keyboard 

I 

40 



REMOTE COMPUTER 



SO " 



APPLICATION 
PROGRAMS 



28 



8NSDOCID: ^EP „_12C?546A2_L:. 



EP 1 267 548 A2 




BNSDOCID: *EP. 1 267548A? J_ » 



29 



EP 1 267 548 A2 



74 



SIP Client' 
(Caller) 



J K 



ProxyJI <jPsec or SSL pipe> Proxy_2 




407 + 

Proxy-Authenticate 



INVITE + 
Proxy-Authorization 
(Kerberos; 
mutual auth 



200 OK 
Proxy-Authenticatelnfo 




120 



96 

110 
112 





FfG. 3 



86 



V SIP Client 
(Callee) 



BNSOOCiO: <EP 1267MBA2 



30 



EP 1 267 548 A2 




^150 

407 Challenge 
on any request 



FIG. 4 



31 



EP 1 267 548 A2 



72 

SIP Client^/ 
(Caller) 



74 



120 



ProxyV iPsec or SSL pipe^> Proxy_2 




407 + 
Proxy-Authenticate 



INVITE + 
Proxy-Authorization 
kerberos mutual auth) 

112 




200 OK + 
Proxy-Authenticatelnfo 



INVITE + 
Proxy-Authorization 
Kerberos mutual auth) 




96 



'110 



407 + 
Proxy-Authenticate 




^-~192 



200 OK + 
Proxy-Authenticatelnfo 




FIG. 5 



s 190 



86 



SIP Client 
v (Callee) 




32 



E5NSDOCID: <ZP , „l2e754BA2_l. 



72 \ 

SIP Client 



FIG. 6 



EP 1 267 548 A2 



REGISTER + 
Proxy-Authorization 
(Kerberos) 



200 



J 



f 



74 



200 OK + Proxy- 
Authenticatelnfo 



SIP Proxy 




202 



72 



SIP Client 



FIG. 7 



INVITE 
(w/o auth) 



206 



SIP Proxy 





407 + 
Proxy-Authenticate 


.^208 










REGISTER + 
Proxy-Authorization 
(Kerberos) 


210 






200 OK + Proxy- 
Authenticatelnfo 


-X 


s ^ 212 

. 



INVITE + 
Proxy-Authorization 
(Kerberos) 



214 



33 



BNSDOCID: <£P. 



t?67S43A2^L> 



EP 1 267 548 A2 



72 



SIP Client 



Y 1 * 

SIP Proxy 







REGISTER + 


224 






Proxy-Authorization 




FIG. 8 




(NTLM) 









INVITE 
(w/o auth) 



220 



407 

Proxy-Authenticate 



222 



407 + 
Proxy-Auth enticat e 



-226 





REGISTER + 


228 




Proxy-Authorization 






(NTLM) 








200 OK + Proxy- 






Authenticatelnfo 


232 



INVITE + 
Proxy-Authorization 
(NTLM) 



236 



..l267f>48A2.J..> 



34 



EP 1 267 548 A2 



72 X 

SIP Client 



FIG. 9 



REGISTER + 
Proxy-Authorization 
(NTLM) 



407 + 
Proxy-Authenticate 



REGISTER + 
Proxy-Authorization 
(NTLM) 



200 OK + Proxy- 
Authenticatelnfo 



r 74 

SIP Proxy 



24.0 



242 



244 



INVITE + 
Proxy-Authorization 
(NTLM) 



246 



248 



35 



BNSDOCID: <EI>. 



(19) 



J 



Europe isches Patentamt 
European Patent Office 
Office europeen des brevets 



(12) 



(88) Dato of publication A3: 

20.04.2005 Bulletin 2005/16 



(ID EP1 267 548 A3 

EUROPEAN PATENT APPLICATION 

(51) IntCI 7 : H04L 29/06 



(43) Date of publication A2: 

18.12.2002 Bulletin 2002/51 

(21) Application number: 02013408.6 

(22) Date of filing: 12.06.2002 



(84) Designated Contracting States: 


(72) Inventors: 


AT BE CH CY OE DK ES Fl FR GB GR IE IT LI LU 


• Bobde. Nikhil P. 


MC NL PT SE TR 


Bellvue, Washington 98052 (US) 


Designated Extension States: 


* Demirtjis, Ann 


AL LT LV MK RO SI 


Redmond, Washington 98052 (US) 




• Han, Mu 


(30) Priority: 14.06.2001 US 298239 P 


Redmond, Washington 98052 (US) 


17.05.2002 US 151747 






(74) Representative: GrOnecker, Kinkeldey, 


(71) Applicant: MICROSOFT CORPORATION 


Stockmair & SchwanhSusser Anwaitsso2ietat 


Redmond, WA 98052 (US) 


Maximilsanstrasse 58 




80538 Munchen (DE) 



CO 

< 

00 

in 

N 
CO 
CM 



(54) Method and system for integrating security mechanisms into session initiation protocol 
request messages for client-proxy authentication 



(57) A method and system is provided to integrate 
the Kerberos security mechanism into the message flow 
of the signaling operation under the Session Initiation 
Protocol to allow a SIP client and a SIP proxy to authen- 
ticate each other. When the SIP proxy receives an re- 
quest message, such an INVITE request, from the SIP 
client, it responds with a challenge message indicating 
that authentication based on Kerberos is required. In re- 
sponse, the SIP client sends a second request message 
with a proxy authorization header containing authenti- 
cation data, including a Kerberos server ticket for the 
Proxy, to allow the proxy to authenticate the client's user 



I ~ — I 

! — * 



=1 



-a 



T i 



Figure 1 



CL 
Hi 



Printed by Jouve. 75001 PAHlS (FR) 



BNSDCC1D: *EP^ 1267546A3J. > 



EP 1 267 548 A3 



European Patent 
Office 



EUROPEAN SEARCH REPORT 



Application Number 

EP 02 01 3408 



DOCUMENTS CONSIDERED TO BE RELEVANT 



Category 



Citation of document with indication, where appropriate, 
_ ol re levant pas sages \ 



Relevant 
to claim 



SONG D. : "Kerberos on the Web: Protocol 
example" 

INTERNET ARCHIVE, [Online] 
11 May 20O1 (2001-05-11). XP002318213 
Retrieved from the Internet: 
URL: http://web.archive.org/web/200 10511171 
619/http: //www. monkey, org/~dugsong/krb-www 
/kapache/ KRB_PR0T . HTM> 
[retrieved on 2005-02-15] 
the whole document * 

TSCHALAR ~R ET AL: M Kerberos 
authentication and authentication (proxy 
ticket forwarding)" 

APACHE DEVELOPMENT MAILING LIST, [Online] 
6 November 1999 (1999-11-06), XPO02318214 
Retrieved from the Internet: 
URL:http://hypermai 1 . 1 inklord. com/new-http 
d . o 1 d/ 1999/ Nov/0 106 . html > 
[retrieved on 2005-02-15] 
* the whole document * 



1-5, 

8-11,13 

14,16, 

17,19, 

20,23-28 



HANDLEY M ET AL: "RFC 2543 SIP 
Initiation Protocol" 
NETWORK WORKING GROUP REQUEST FOR 
COMMENTS, March 1999 (1999-03), 
XP015008326 

* page 15 - page 16; figure 1 * 

* page 45 * 

* page 60 - page 61 * 

* page 109 * 

* page 113 - page 115 * 



Session 



CLASSIFICATION OF THE 
APPLICATION (lnt.CI.7l 



H04L29/06 



1,7.8,15 



-/- 



The present search report has been drawn up for all claims 



1-3.8,9. 
13 



4-7, 

10-12, 

14-28 



The Hague 



r)3j* r,{ wwpiftift'i fll It* wait* 

22 February 2005 



TECHNICAL FIELDS 
SEARCHED (lnl.CI.7) 



H04L 



Examin*: 

Ruiz. Sanchez, J 



CATEGORY OF CITED DOCUMENTS 

X particularly relevant if taken aione 

Y : particularly relevant if oombtn»d with another 

document or the same category 
A: technological background 
O • non-wntten disclosure 
P : intormediate document 



T : theory or principle underlying the snvention 
E : earlier patent document, but published or». or 

after the filing date 
D : document cited >n the application 
L : document cited for other reason* 

& "■ member of the same patent family, corresponding 
document 



2 



BKSDOClD: , !26754eA3 J..» 



EP 1 267 548 A3 



European Patent 
Office 



EUROPEAN SEARCH REPORT 



Application Number 

EP 02 01 3408 



DOCUMENTS CONSIDERED TO BE RELEVANT 



Category 



Citation of document with indication, whore appropriate, 
of relevant passages 



| ReievanJ 
_j to claim 



CLASSIFICATION OF THE 
APPLICATION (lnLCl.7> 



NOKIA: "UMTS AKA in SIP" 
3GPP TSG WG3 S3#14, 

4 August 2000 (2000-08-04) , XP002318333 
* the whole document * 



BYERLY B J ET AL: "SIP Authentication 

using CHAP- Pas sword" 

IETF INTERNET DRAFT, 

October 2000 (2000-10), pages 1-12, 

XP002279177 

* section 1 * 

* section 3,2 * 

* section 4.3 * 

* section 7 * 

* section 9 * 



il-3,8,9 

!13 



U-3.8,9, 

;13 



TECHNICAL FIELDS 
SEARCHED <lnLCI.7) 



The present search report has been drawn up for &\\ claims 



The Hague 



Case d correction ct i™ tt-aich 

22 February 2005 



Ruiz Sanchez, J 



CATEGORY OF CITED DOCUMENT 3 

X : particularly relevant It taken aione 

Y . particularly relevant if combined with another 

document d the name category 
A : technological background 
O : non-written disclosure 
P ■ trrtermedtalft document 



T . theory ot prinoipfe underlying, the invention 
£ : earlier patent document, but published on, or 

after the Ming date 
D : document cited in the application 
L : document cited tor other reaaons 

& : member of the tame patent family, conetponding 
document 



•NSDOCiD: <EP. 



1267548A9.I„> 



